Presently, database environments are predominately based on a two-tiered model consisting of one or more applications in a top tier which access a database management system (DBMS) server in the bottom tier. Each application sends queries to the DBMS server which processes the queries and returns results sets. The two-tiered model suffers from several drawbacks. First, the queries must be formulated in a DBMS-specific query language, such as Structured Query Language (SQL), known to the server. Often the query language is non-standard as a result of proprietary extensions made to the basic query language. As a result, queries are often non-portable between different DBMS servers. Second, commonly performed routines must be replicated between peer applications since each application functions autonomously from its peers. The replication results in poor code re-use and duplication of functions.
Consequently, there is a trend towards a three-tiered model for database environments. Generally, the top tier consists of clients, the middle tier consists of application or business logic and the bottom tier consists of DBMS servers. In this model, the applications are implemented as "thin" clients with the commonly performed routines consolidated into the middle tier as the business logic. Since the business logic is shareable between the clients, code replication is avoided. The Common Object Request Broker Architecture (CORBA) presents one object-oriented approach to forming a three-tiered database environment, such as described in R. Orfali et al., "The Essential Client/Server Survival Guide," pp. 375-458, John Wiley & Sons, Inc. (2d ed. 1996), the disclosure of which is incorporated herein by reference.
Existing DBMS access mechanisms and tools, including fourth generation languages (4GLs) and application programmer interfaces (APIs), are designed for the two-tiered model and are ill-suited for use in the three-tiered model. The construction of business logic for the middle tier is particularly difficult and several work-around approaches exist.
One prior art approach to interfacing to a database server in a three-tiered model uses database objects, such as licensed by I-Kinetics, Inc. Each database object is implemented as a middle tier server that passes an API for the DBMS from the DBMS server to the database object. The clients pass queries into the database object via the API and receive results sets back. This approach provides the full power of the DBMS query engine to the applications, but provides no abstraction from the query engine. Thus, the applications are tied to the query language and schema of the DBMS. The database objects approach is further described hereinbelow with reference to FIG. 2 in the Detailed Description.
Another prior art approach to interfacing to a database server in a three-tiered model uses active data object, such as licensed by Persistence, Inc. Each active data object is implemented in the middle tier for use by other objects also in the middle tier. Data from the database is mapped into each active data object which perform the actual queries to the database. This approach provides substantial abstraction by limiting what the application "sees" to only the resultant objects. However, active data objects give up most of the power of the query engine, such as for summarizing data mapped to large numbers of objects. The active data objects approach is further described hereinbelow with reference to FIG. 3 in the Detailed Description.
Therefore, there is a need for an approach to providing improved database interfacing in a three-tiered model. Such an approach would abstract the queries and schema of the bottom tier DBMS server without giving up the full power of the query engine. The approach could preferably be generalized to operate on other forms of organized data, including relational, hierarchical and other formal databases to simple flat files.
There is a further need for an approach to interfacing to a DBMS in a distributed computing environment using object oriented programming technologies. Such an approach would preferably encapsulate the DBMS query language, database schema and DBMS API from the application, thereby enabling the data object layer to be bypassed.